|
The server computer can be connected to the Internet via various TCP connection links: a direct, permanent (24x7) Internet link can be available, a simple single-user PPP software (such as FreePPP or OT/PPP) can be used, or your server computer can have access to a dial-up TCP router installed on the server computer or the Server network.
When you use the OT/PPP or FreePPP "single user" software, you are not supposed to receive any incoming TCP connections with your CommuniGate Server (with one exception). Most likely, your server does not even have a static IP address that can be used to connect to the server. As a result, the CommuniGate Server can serve only AppleTalk-based client applications, such as the CommuniGator or Claris Emailer in the AppleTalk mode.If you want to server TCP/IP-based client applications (such as Eudora®), please read the Serving POP and IMAP Clients document.
When using a single-user dial-up software, check that:
If you change any of these setting, the CommuniGate module will send so called "unconditional requests", keeping the TCP software ready for incoming connections. This will result in re-dialing and re-connecting to the Internet as soon as the link is dropped.
- POP Service Settings
- the TCP Channels option in Serving POP Clients field is set to zero.
- SMTP Service Settings
- the TCP Channels in the Receiving Options is set to zero.
If you do use SMTP to receive incoming connections and to retrieve Internet mail (SMTP feeds), you should set the number of channels to non-zero, and you should not select the Always Keep Ready option: disabling this option tells the SMTP module to prepare for receiving only at the specified time intervals.- IMAP Service Settings
- The TCP Channels option in the Serve IMAP Clients field is set to zero.
- PWD Service Settings
- The TCP Channels option in the Serve PWD Clients field is set to zero.
- UUCP Service Settings
- The Accept TCP Connections option is not selected.
If your Server is equipped with the FreePPP software, make sure you have configured the FreePPP software properly.
If your Server is equipped with the OT/PPP (or ARA 3.0) software, make sure you have configured the OT/PPP software properly.
When your network has a direct Internet link or it has a dial-up Internet Router installed, your CommuniGate Server can accept TCP connections from applications running on other computers on the local network. As a result, the CommuniGate Server (and communication modules) can serve TCP-based mailer applications. Read the Serving POP and IMAP Clients document for the details.If your Server is equipped with the Vicomsoft Internet Gateway software, make sure you have configured the Vicomsoft Gateway software properly.
When the Server computer employs a dial-up Internet link, it is important to restrict the System TCP/IP activity to keep the connection time as short as possible.All CommuniGate modules consult the CommuniGate Server kernel before they start any TCP activity. This method allows for centralized administrating of the CommuniGate System TCP activity.
A module that wants to start a TCP session passes the priority value with the activity request. The CommuniGate Server may allow the module to start a high priority activity while rejecting regular-priority and the low-priority requests.
If the CommuniGate Server rejects a request, the module displays the TCP/IP Link is Down message in the module status, and the module repeats an attempt later (usually, in 1 minute).
If the CommuniGate Server has initiated a dial-up link, but a TCP/IP connection has not been established yet, the CommuniGate Server rejects a request, the module displays the Establishing a TCP/IP Link message, and the module repeats an attempt later (usually - in 10-25 seconds).
See the CommuniGate Modules manuals for the details.
If some of the POP accounts cannot be polled because a remote POP server is down, or if the SMTP module cannot access a "foreign mail server" because that server is not working, repeating attempts these module make may result in excessive phone costs for your dial-up system. To avoid this problem use the TCP Schedule settings to specify how often TCP connections can be initiated.
If you have many users, then allowing the Server to start TCP activity immediately, as soon as any module sends a request, will cause the Server to initiate TCP links every time any user sends a message or when a user has a scheduled polling of an individual POP mailbox on a remote host. When the "how often" setting is set to 15 minutes, all submitted messages will stay in the SMTP queue, and dial-up links to the Internet will be established every 15 minutes. When a connection is established, all messages submitted by all users are sent, and all scheduled pollings of remote POP accounts are performed. If there is no message to send and no POP account to poll, the modules do not send requests to the Server, and the Server does not initiate dial-up links.
Choose General from the Server menu. The TCP Schedule Settings dialog box appears.
You can create a TCP Schedule using the settings in this field. Each line specify the day (or days) of week, and the daytime interval. For each interval created the last setting specifies how often TCP/IP activity can be initiated.When a low- or regular- priority request is received, the Schedule is checked.
The sample above allows the Server to initiate TCP Sessions every 5 minutes (if needed) during the working hours (6:00 a.m. - 6:00 p.m.) on weekdays, every hour afterhours (including the period from midnight to 6:00 a.m. on Monday and from 6:00 p.m. till midnight on Friday), and every 4 hours during weekends.
A request to start TCP Activity is accepted if the TCP link is still active and that link was initiated less than 2 minutes ago. If a link is up for more than 2 minutes, every new request is accepted only if allowed with the TCP Schedule.
When some of your modules are configured to receive incoming TCP connections (if you use an Internet Router), these module send special "unconditional" requests to the Server. These requests are always satisfied (expect for the first 2 minutes of the Server activity), since these actions do not start any real TCP/IP activity - the modules just allocate the TCP resources required to accept incoming connections. When processing these requests, the Server ignores the TCP Schedule settings.